1. Field of the Invention
This invention relates in general to the field of interrupt handling in computer systems, and more particularly to handling a floating point error interrupt after transition of an interrupt mask flag.
2. Description of the Related Art
Within a computing system, input/output (I/O) devices often require assistance, or servicing, by a processor. To communicate with the processor, I/O devices use a signal line known as an interrupt request line to request the processor's assistance.
The kind of servicing which an I/O device needs is defined by the type of device and its current condition. For example, a parallel port connected to a printer may generate an interrupt request to ask the processor for the next character to be sent to the printer. In this case, the processor would respond by performing an I/O write bus cycle to send the next character to the parallel port.
Another example would be the interrupt request generated by a hard disk controller to tell the processor that a data transfer to or from memory has been completed. If this were a disk read operation, for example, the processor would respond to the interrupt request by using the data that has been transferred from the disk controller into memory.
A third example would be when a keyboard interface generates an interrupt request to inform the processor that a key has been pressed. The processor should respond by performing an I/O read from the keyboard interface to get the keyboard character.
In each of the above cases, the processor responds to an interrupt request by executing a special program known as an interrupt service routine. The interrupt service routine's task is to service the request. Different types of interrupt requests require different types of servicing on the part of the processor. This means that there must be a separate interrupt service routine for each type of interrupt request that can be generated by the various I/O devices connected to the processor.
When an interrupt occurs, the processor temporarily suspends execution of the current program and forces it to jump to another program, the interrupt service routine. At the conclusion of the interrupt service routine, the processor returns program flow at the point where it was interrupted.
To better illustrate interrupts, and their effect on program flow, attention is directed to FIGS. 1 and 2.
Referring to FIG. 1, a computer system 100 is shown. The computer system 100 includes a microprocessor 102 connected to a data bus 104. The microprocessor 102 is also connected to an interrupt controller 106 via an interrupt line 108 and a control bus 110. The interrupt controller 106 is connected to a plurality of hardware devices including: a system timer 112, a keyboard interface 114, a serial port 116, a floppy disk controller 118, a hard disk controller 120 and a parallel port 122. Also connected to the interrupt controller are a number of expansion slots 124.
In operation, when any of the hardware devices 112-124 wish to communicate with the microprocessor 102, they provide a signal to the interrupt controller 106. The interrupt controller is used as an interface between the microprocessor 102 and the hardware devices 112-124. The interrupt controller 106 receives signals from the hardware devices 112-124, determines which hardware device 112-124 requires access to the microprocessor 102, and sends an interrupt signal on line 108 to the microprocessor 102. In addition, the interrupt controller 106 utilizes the data bus 104, and the control bus 110 to communicate with the microprocessor 102 to let it know which hardware device 112-124 requires attention. The interrupt causes the microprocessor 102 to temporarily suspend execution of the current program and forces it to jump to another program, called the interrupt service routine, or ISR. After the microprocessor 102 services the interrupt, it returns to the original program at the point of interruption, and sends a signal to the interrupt controller 106 to clear the interrupt.
Now referring to FIG. 2, a diagram 200 illustrating program flow during an interrupt is shown. It should be understood that the program as shown, could be executed on the microprocessor 102 of FIG. 1. A program 202 is executing on the microprocessor 102 when the processor receives an interrupt on interrupt line 108. If the interrupt arrives during execution of an instruction 208, the interrupt will cause a branch 204 at position 210 (upon the completion of instruction 208). The branch 204 transfers execution from the executing program 202 to an exception handler 206. More specifically, program flow begins with an instruction service routine 212 which handles the interrupt condition. Upon completion of the interrupt service routine 212, program flow branches back to the executing program 202 at position 210.
What is illustrated by the above is how an interrupt condition causes interruption in program flow, from an executing program 202 to an interrupt service routine 212. However, interruption of program flow in an executing program is not always desirous, and depending on the executing program, can create serious problems. To prevent interrupts from interfering with the program flow of particular programs, interrupts are often "masked" by the processor during execution of those programs.
Within the microprocessor 102 is a control register, or EFLAGS register (not shown), which contains a number of status bits, or flags, which are used to control I/O, interrupts, debugging and task switching. One of these flags is called the Interrupt Flag, or simply the IF bit. When this bit is cleared (i.e., equal to 0), then interrupts are said to be "masked". When the IF bit is set (i.e., equal to 1), then interrupts are allowed. By clearing the IF bit prior to execution of an interrupt sensitive program, interrupts are ignored during execution of that program. Upon completion of the program, the IF bit is set, which allows interrupts to be handled.
In x86 processors, there are three instructions which when executed, may set the IF bit to allow interrupts. The first two instructions, POPF and IRET, overwrite the contents of the control register with a previously stored value. If the IF bit was set in the previously stored control register value, then upon completion of execution of either of these instructions, interrupts will be allowed. In fact, if an interrupt is pending prior to execution of POPF or IRET, then the interrupt will be handled immediately upon completion of executing the POPF or IRET instruction.
The third instruction which sets the IF bit is the STI, or set interrupt flag, instruction. As with the above two instructions, when the STI instruction is executed, the IF bit is set, which allows the processor to handle interrupts. However, unlike the above two instructions, the architecture of x86 processors requires that if the IF bit was cleared prior to execution of the STI instruction, and if an interrupt is pending, either prior to execution of the STI instruction, or concurrent with the execution of the STI instruction, then interrupts are not to be handled until after execution of the instruction which follows STI. So, even after the STI instruction sets the IF bit to allow interrupts, pending interrupts are not to be recognized until after the processor executes the instruction following STI. Only then may the interrupt be handled. At least this was the stated operation of x86 processors for some time.
In 1995, an errata to the Pentium.RTM. microprocessor was made which corrected a flaw in the architecture. It was determined that if the STI instruction followed a floating point instruction, and if the floating point instruction created an error condition, and if the instruction which followed STI was a floating point instruction, then a pending interrupt must be handled immediately after execution of the STI instruction. Otherwise, the processor would hang waiting for the floating point error to clear prior to execution of the floating point instruction following STI. The errata therefore changed the specification of the processor to require that upon execution of the STI instruction, if the IF bit was previously clear, and if an interrupt is pending upon completion of the STI instruction, then the interrupt is not to be handled until after execution of the instruction following STI, unless the next instruction is a floating point instruction. In that instance, the interrupt is to be handled immediately.
So, the rule as it stands today, is to allow interrupts immediately after POPF and IRET instructions set the IF bit, to delay handling interrupts for one instruction after the STI instruction sets the IF bit, but to handle interrupts immediately after the STI instruction if the instruction following STI is a floating point instruction.
To implement the rule as stated above has heretofore required significant hardware within a microprocessor to determine whether interrupts are to be allowed after transition of the IF bit. The processor must determine what instruction was being executed at the time the IF bit made a transition (i.e., was it STI, POPF or IRET), whether the prior state of the IF bit was 1 or 0, and whether the instruction which follows the IF bit transition is a floating point instruction. For the processor to monitor each of these conditions, and implement the rule in a timely fashion, costly circuitry surrounding the control register, and the instruction decode/sequencing logic is required. In addition, once the circuitry is designed and placed within a processor, future modifications to the rule will require redesign of the circuitry within the processor. Such redesign is very costly, time consuming, and places manufacturers of x86 processors at a disadvantage when architectural changes are made.
The errata also required that if an STI instruction was followed by a floating point instruction, it was necessary to place an instruction between the STI instruction and the floating point instruction. Otherwise, the x86 processor would hang. Use of a 3rd instruction, such as a NOP, wastes both programming space, and execution time.